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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document is part of a series of documents specifying charging functionahty and charging management in 
GSM/UMTS networks. The GSM/UMTS core network charging architecture and principles are specified in 
3GPP TS 32.240 [1] which provides an umbrella for other charging management documents that specify: 

• the content of the CDRs per domain / subsystem / service (offline charging); 

• the content of real-time charging messages per domain / subsystem / service (online charging); 

• the functionality of online and offline charging for those domains / subsystems / services; 

• the interfaces that are used in the charging framework to transfer the charging information (i.e. CDRs or 
charging events). 

The complete document structure for these TSs is defined in 3GPP TS 32.240 [1]. 

The present document specifies the mechanisms used to transfer CDR files from the network to the operator's billing 
domain (e.g. the billing system or a mediation device). This includes the file transfer procedures and the layout of the 
CDR files, as well as file meta information and the encoding of the CDRs within the files. 

The CDR types that can be transported in these files are specified in the respective 'middle tier' charging TSs, i.e. 3GPP 
TS 32.25x - 3GPP TS 32.27x. A definition of the parameters, abstract syntax and encoding rules for these CDR types is 
specified in 3GPP TS 32.298 [51]. 

Note that the present document, dealing with CDRs, is consequently only concerned with offline charging. A definition 
of the corresponding 3GPP online charging functionality and applications can be found in 3GPP TS 32.299 [50]. 
Furthermore, 3GPP TS 32.296 [53] specifies the OCS internal charging applications and interfaces. 

All terms, definitions and abbreviations used in the present document, that are common across 3GPP TSs, are defined in 
the 3GPP Vocabulary, 3GPP TR 2 1.905 [100]. Those that are common across charging management in GSM/UMTS 
domains, services or subsystems are provided in the umbrella document 3GPP TS 32.240 [1] and are copied into clause 
3 of the present document for ease of reading. Finally, those items that are specific to the present document are defined 
exclusively in the present document. 

Furthermore, requirements that govern the charging work are specified in 3GPP TS 22.1 15 [102]. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[1] 3GPP TS 32.240: "Telecommunication management; Charging management; Charging 

architecture and principles". 

[2]-[9] Void. 

[10] 3GPP TS 32.250: "Telecommunication management; Charging management; Circuit Switched 

(CS) domain charging". 

[ll]-[29] Void. 
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[30] 3GPP TS 32.270: "Telecommunication management; Charging management; Multimedia 

Messaging Service (MMS) charging". 

[31]-[49] Void. 

[50] 3GPP TS 32.299: "Telecommunication management; Charging management; Diameter charging 

application". 

[51] 3GPP TS 32.298: "Telecommunication management; Charging management; Charging Data 

Record (CDR) encoding rules description". 

[52] Void. 

[53] 3GPP TS 32.296: "Telecommunication management; Charging management; Online Charging 

System (OCS) applications and interfaces". 

[54] 3GPP TS 32.295: "Telecommunication management; Charging management; Charging Data 

Record (CDR) transfer". 

[55]-[99] Void. 

[100] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications". 

[101] 3GPP TS 22.1 15 "Service aspects; Charging and bilhng". 

[102]-[199] Void. 

[200] 3GPP TS 23.078: "Customized AppHcations for Mobile network Enhanced Logic (CAMEL); 

Stage 2". 

[201]-[399] Void 

[400] IETF RFC 959 (1985): "File Transfer Protocol". 

[401]-[499] Void. 

[500] 3GPP TS 32.341: "Telecommunication management; File Transfer (FT) Integration Reference 

Point (IRP): Requirements". 

[501] 3GPP TS 32.342: "Telecommunication management; File Transfer (FT) Integration Reference 

Point (IRP): Information Service (IS)". 

[502] 3GPP TS 32.343: "Telecommunication management; File Transfer (FT) Integration Reference 

Point (IRP): Common Object Request Broker Architecture (CORE A) Solution Set (SS)". 

[503] 3GPP TS 32.344: "Telecommunication management; File Transfer (FT) Integration Reference 

Point (IRP): Common Management Information Protocol (CMIP) Solution Set (SS)". 



3 Definitions, symbols and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in 3GPP TR 21.905 [100], 3GPP TS 32.240 
[1] and the following apply: 

Billing Domain: part of the operator network, which is outside the telecommunication network, that receives and 
processes charging information from the core network charging functions. It includes functions that can provide billing 
mediation and billing or other (e.g. statistical) end applications. It is only applicable to offline charging (see 'Online 
Charging System' for equivalent functionality in online charging). 

CDR field Categories: defined in the middle tier charging TSs. CDR fields may be operator provisionable and are 
divided into the following categories: 
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• Mandatory (M): field that shall always be present in the CDR. 

• Conditional (C): field that shall be present in a CDR if certain conditions are met. 

• Operator Provisionable: Mandatory (Om): field that, if provisioned by the operator, shall always be present in 
the CDR. 



• 



Operator Provisionable: Conditional (Oc): field that, if provisioned by the operator, shall be present in a CDR 
if certain conditions are met. 



charging: function within the telecommunications network and the associated OCS/BD components whereby 
information related to a chargeable event is collected, formatted, transferred and evaluated in order to make it possible 
to determine usage for which the charged party may be billed (offline charging) or the subscriber"s account balance 
may be debited / credited (online charging). 

Charging Data Record (CDR): formatted collection of information about one or more chargeable event(s) (e.g. time 
of call set-up, duration of the call, amount of data transferred, etc) for use in billing and accounting. For each party to be 
charged for parts of or all charges of the chargeable event(s) a separate CDR shall be generated, i.e. more than one CDR 
may be generated for a single chargeable event, e.g. because of its long duration, or because more than one charged 
party is to be charged. 

charging function: entity inside the core network domain, subsystem or service that is involved in charging for that 
domain, subsystem or service. 

circuit switched domain: domain within GSM / UMTS in which information is transferred in circuit switched mode. 

domain: part of the 3GPP telecommunication network that provides network resources using a certain bearer 
technology. 

GPRS: packet switched bearer and radio services for GSM and UMTS systems. 

middle tier (charging) TS: term used for the 3GPP charging TSs that specify the domain / subsystem / service specific, 
online and offline, charging functionality. These are all the TSs in the numbering range from 3GPP TS 32.250 to 3GPP 
TS 32.279, e.g. 3GPP TS 32.250 [10] for the CS domain, or 3GPP TS 32.270 [30] for the MMS service. Currently, 
there is only one "tier 1" charging TS in 3GPP, which is TS 32.240 [1] that specifies the charging architecture and 
principles. Finally, there are a number of top tier charging TSs in the 32.29x numbering range ([50] ff) that specify 
common charging aspects such as parameter definitions, encoding rules, the common billing domain interface or 
common charging applications. 

near real-time: near real-time charging and billing information is to be generated, processed, and transported to a 
desired conclusion in less than 1 minute. 

offline charging: charging mechanism where charging information does not affect, in real-time, the service rendered 

online charging: charging mechanism where charging information can affect, in real-time, the service rendered and 
therefore a direct interaction of the charging mechanism with session/service control is required. 

packet switched domain: domain within the GSM / UMTS core networks in which data is transferred in packet 
switched mode. Corresponds to the term "GPRS". 

real-time: real-time charging and billing information is to be generated, processed, and transported to a desired 
conclusion in less than 1 second. 

3.2 Symbols 

For the purposes of the present document, the following symbols apply: 

Be Reference point for the CDR file transfer from the Circuit Switched CGF to the BD. 

Bg Reference point for the CDR file transfer from the GPRS CGF to the BD. 

Bi Reference point for the CDR file transfer from the IMS CGF to the BD. 

Bl Reference point for the CDR file transfer from the GMLC CGF to the BD. 

Bm Reference point for the CDR file transfer from the MMS CGF to the BD. 

Bmb Reference point for the CDR file transfer from the MBMS CGF to the BD. 

Bo Reference point for the CDR file transfer from the OCF CGF to the BD. 
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Bp Reference point for the CDR file transfer from the PoC CGF to the BD. 

Bs Reference point for the CDR file transfer for CAMEL services to the BD, i.e. from the SCF CGF 

to the BD. 

Bw Reference point for the CDR file transfer from the /-WLAN CGF to the BD. 

Bx Reference point for CDR file transfer between any (generic) 3G domain, subsystem or service 

CGF and the BD. 

Ga Reference point for CDR transfer between a CDF and the CGF. 

Rf Offline Charging Reference Point between the CTF within a 3G network entity and the CDF. 

3.3 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

3G S"'^ Generation 

bed binary coded decimal 

BD Billing Domain 

CAMEL Customised Applications for Mobile network Enhanced Logic 

CDF Charging Data Function 

CDR Charging Data Record 

CGF Charging Gateway Function 

CS Circuit Switched 

CTF Charging Trigger Function 

FTP File Transfer Protocol 

GMLC Gateway MLC 

GPRS General Packet Radio Service 

IMS IP Multimedia Subsystem 

IP Internet Protocol 

I- WLAN Interworking WLAN 

LAN Local Area Network 

MBMS Multimedia Broadcast/Multicast Service 

MLC Mobile Location Center 

MMS Multimedia Messaging Service 

OAM&P Operation, Administration, Maintenance and Provisioning 

OCF Online Charging Function 

OCS Online Charging System 

PoC Push-to-talk over Cellular 

PS Packet Switched 

SCF Service Control Function 

UTC Universal Time Coordinated 

WLAN Wireless LAN 



Architecture considerations 



"Bx" is a common designator for the reference points from the network to the billing domain (BD) that are intended for 
the transport of CDR files. The letter 'x' indicates the different 3GPP network domain, subsystem or service, where 

c represents Circuit Switched (CS), 

g represents Packet Switched (GPRS), 

i represents IP Multimedia Subsystem (IMS), 

I represents Location Service (LCS), 

m represents Multimedia Messaging Service (MMS), 

mb represents Multimedia Broadcast/Multicast Service (MBMS), 

o represents the Online Charging System (OCS), 

p represents the PoC service. 
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s represents the CAMEL SCF, and 

w represents interworking Wireless LAN (I-WLAN). 

By definition, dealing with CDR files only implies that Bx is solely related to offline charging. The following figure 
depicts the position of the Bx reference point within the overall 3GPP offline charging architecture. 
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CTF: Charging Trigger Function 

CDF: Charging Data Function 

CGF: Charging Gateway Function 

BD: Billing Domain. This may also be a billing system/ billing mediation device. 

Figure 4.1 : Logical ubiquitous offline charging architecture 

As illustrated in figure 4.1, the CGF in each network domain, service or subsystem is relevant for the network side of 
the Bx reference point and is connected with the BD that forms the receiving end of the Bx reference point. Further 
details of the Billing Domain, i.e. beyond terminating Bx, are outside the scope of 3GPP standardization. Refer to 
3GPP TS 32.240 [1] for the complete description of the 3GPP charging architecture. 

Note that the OCS can also generate CDRs and transfer them to the BD across the Bo reference point (not depicted in 
figure 4.1). Refer to 3GPP TS 32.296 [53] for further information on the OCS. 

Furthermore the GSM SCF, defined in CAMEL, can also generate CDRs and transfer them to the BD across the Bs 
reference point (not depicted in figure 4.1). Refer to 3GPP TS 23.078 [200] for further information on CAMEL. 
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5 CDR File Transfer Principles and Scenarios 

This clause contains specifications for the principles and scenarios covering the CDR file transfer interface from the 
network to the Billing Domain. These specifications apply to all domains, subsystems and services that are listed in 
clause 4, including the OCS Bo and the GSM SCF"s Bs interface. Alternatively, in the CS domain (i.e. for Be), the file 
transfer mechanism specified in 3GPP TS 32.250 [10] may be used. Consequently, for Be it is up to implementation 
choice to provide either the legacy interface, the interface specified in the present document, or both. 

The scenarios in this clause are divided into the following categories: 

• Local CDR and CDR file handhng; 

• File format principles; 

• File Transport and protocol; 

• File transfer modes and session management. 

Other interface principles such as security and performance are dependent on vendor implementation and operator's 
network design and are not covered by the present document. 

5.1 Local CDR and CDR file handling 
5.1.1 CDR processing 

As depicted in figure 4.1. above, the CGF collects CDRs from the CDF. If the CDF and the CGF are separate entities, 
then the standard Ga interface as specified in 3GPP TS 32.295 [54] is used to transfer the CDRs from the CDF to the 
CGF. If CDF and CGF are integrated, then a proprietary, internal mechanism is used. The possibilities of separate or 
integrated CDF and CGF are specified per domain, subsystem and service in the respective "middle tier" charging TS, 
i.e. those in the [10] through [49] reference number range, and in TS 32.296 [53] for the OCS. 

In any case, CDRs are transferred, in near real time, from the CDF to the CGF as soon as they have been closed by the 
CDF. Refer to 3GPP TS 32.295 [54] for further details. Once received by the CGF, the CDRs may undergo semantical 
and/or syntactical sanity checks, however, these checks are not specified further within the present document. 

If the CGF determines that a CDR is not well formatted, or otherwise incorrect, then the defective CDR parameter(s) 
shall be filled with an appropriate "replacement" indicator within the limits of the syntax allowed for the parameter. If 
the error renders the complete CDR unusable (i.e. the above replacement of erroneous parameters is not possible), then 
no further action of the CGF can be performed regarding this CDR. An example of a case where the erroneous 
parameter cannot be replaced is when the "CDR type" attribute of a CDR received by the CGF is corrupted. Details of 
this function are implementation specific. 

CDRs that have been processed by the CGF without error, or where errors have been corrected by the CGF as described 
above, are considered "acceptable" by the CGF. CDRs that have non-recoverable errors are not considered "acceptable" 
by the CGF. The "acceptable" CDRs are immediately placed into a CDR file by the CGF. The CDRs that are not 
"acceptable" should be properly reflected in an error log and appropriate alarms should be generated, after which they 
may be destroyed. Furthermore, to the extent possible, the number of lost CDRs and the fact that CDRs were lost, shall 
be indicated in the CDR file. 

It is acknowledged that the processing of a CDR between being received until it is placed on the CDR file, will take a 
small amount of time. Hence, where the present document mandates the "immediate" treatment of CDRs received by 
the CGF, it is to be interpreted such that it is not allowed to postpone the processing of any received CDRs for any 
reason. In technical terms, "immediate" shall be interpreted as 

• The system shall be capable of complying with near real time requirements as specified in subclause 3.1. 

• The system should be capable of complying, as closely as possible, with real time requirements as specified in 
subclause 3.1. 

Once a CDR has been stored on the appropriate file, the CGF may destroy any other reference to that CDR. 
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5.1.2 CDRrouteing 



In the default mode of operation, the CGF manages a single ("default") file for the storage of all "acceptable" CDRs. 
However, the CGF may also route CDRs to different files that are kept open concurrently, i.e. additional files may be 
configured by OAM&P commands together with associated CDR routeing filters. While the CGF will store only those 
CDRs matching the associated routeing filter on each of the additional files, the default file is used to store all CDRs 
that do not match any of the routeing filters configured for the additional files. 

The CDR routeing function shall apply CDR parameters and CDR origin to decide into which file to place the CDR. 
The file name shall, within the limits of the file naming conventions, contain an indication of the CDR routeing filter 
apphed. 

As a minimum, each CGF implementation shall support the CDR type and the sending CDF as selection criteria for 
CDR routeing. It shall then be possible to include in a file only the following CDRs: 

• CDRs of a single type; 

• CDRs of a set of specified types (e.g. only IMS CDR types); 

• CDRs originated by a single CDF; 

• CDRs originated by a set of CDFs; 

• Any combination of the above. 

Further details of the CDR routeing function, such as 

• the maximum number of simultaneously open CDR files; 

• the order in which the routeing filters are evaluated; 

• the way CDR filters can be configured by OAM&P; 

are implementation specific. In order to avoid arbitrary routeing of CDRs, operators should assure that the routeing 
filters assigned per file, do not overlap with each other. 

The term "matching CDR" is used in the present document to denote a CDR that matches the routeing filter of a given 
CDR file. 



5.1 .3 Local CDR file management 



For the default case, plus each of the additional CDR routeing filters that may be set up on the CGF (cf. subclause 5.1.2 
above), the CGF provides a non-interrupted chain of CDR files. As described above, each CDR is immediately stored in 
the appropriate file after being received and determined "acceptable" by the CGF. 

Several conditions may govern the closure of a CDR file by the CGF: 

• A configurable file size limit; 

• A configurable file closure time; 

• A configurable file lifetime ("interval"); 

• A configurable number of CDRs within the file; 

• CDR release, version or encoding change; 

• Manual OAM&P actions; 

• System defined reasons (e.g. file system full). 

When a CDR file is closed, the next matching CDR shall be placed in the next file in the chain. The exact time when 
this next CDR file is physically generated, i.e.: 

• immediately after the previous file has been closed (i.e. the earliest possible time). 
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• when the next matching CDR anives (i.e. the latest possible time), 

• anytime in between, 

is implementation specific. However, each CDR file must contain all "acceptable" matching CDRs received and 
processed by the CGF between the closure of the previous file and the configured file closure trigger of the current file, 
as specified above. In any case, a file must be generated and closed upon the occurrence of the file closure trigger, 
i.e. an empty file (containing no CDRs) if no matching CDRs arrived since the closure of the last file in the chain. Upon 
file closure, the CDR file is immediately available for transfer to the BD. 

CDR files may be removed from the CGF in one of the following ways: 

• By the BD issuing corresponding commands provided by the file transfer protocol; 

• By the CGF application once the file has been transferred; 

• Due to CGF file system storage limitation or configurable file age limits; 

• OAM&P action. 

In order to avoid loss of CDRs, Operators should manage the system in a way that the "system defined" file closure 
triggers mentioned above do not occur. 

5.2 File format principles 

The CDR file format is depicted below. 



r 



Concatenated CDRs 



Header with Specified Length 




CDR1 


CDR 2 


CDR 3 


CDR 4 


CDRS 




CDRn 



Figure 5.2.1 : CDR File Format 

The CDR files contain a variable length header section followed by a variable sized CDR data section. The CDR data 
section contains zero or more concatenated CDRs. Each CDR in a file includes a header indicating the CDR length, data 
record format, release, version and encoding scheme. 

The BD should use a decoder with a version number which is equal or greater of this version to be able to decode all the 
CDRs in the file. 

Clause 6 of the present document specifies the file format applying the above principles at bit level detail. 
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5.3 File Transport and protocol 

Two mechanisms are defined for the transport of CDR files from the CGF to the BD: 

• A basic transport mechanism is defined in subclause 5.3.1 and must be supported by all CGF implementations; 

• The use of the File Transfer IRP as described in subclause 5.3.2 may additionally be supported by the CGF as 
an implementation option. 

5.3.1 Basic file transport mechanism 

The following stipulations govern the choice and usage of file transport protocol for this transport mechanism. 

a) The default protocol for CDR file transport is FTP (RFC 959 [400]). 

b) The use of other protocols is optional, however FTP must always be supported. 

c) The CDR files may be transferred in either push or pull mode on the Bx interface. Further specifications of these 
transfer modes are provided in subclause 5.4.1 and subclause 5.4.2, respectively. 

d) All standard FTP commands specified in RFC 959 [400] shall be supported by the CGF. 

All further requirements specified within the present document with reference to the operation of the file transfer 
protocol in this mechanism (cf. clause 6), are solely related to FTP as the transfer protocol, as no assumptions can be 
made as to the ways of working of optional other protocols. However, additional protocols shall be implemented such 
that, to the extent possible, the same logic is applied as described in the present document for FTP. 

5.3.2 Use of File Transfer IRP 

The File Transfer IRP is specified in 3GPP TSs 32.341 [500], 32.342 [501], 32.343 [502] and 32.344 [503]. The support 
of the solution sets (CORBA, CMIP or both) is left to implementation choice. Otherwise, the CGF implementation of 
the IRP shall comply with the above TSs, i.e. there are no further additions or limitations with regard to the use of the 
IRP in charging. 

5.4 File transfer modes and session management 
5.4.1 Basic file transfer mechanism 

Files can be transferred to the BD in one, or both, of the following modes. Detailed FTP file transfer and session 
management procedures are specified in clause 6. 

5.4.1.1 Push mode 

In this transfer mode the CDR files are written from the CGF to the BD filestore at a time and/or frequency controlled 
by the CGF. I.e. the CGF pushes the files to the BD. This implies that the CGF operates in client mode and the BD in 
server mode. If the CGF generates concurrent CDR files based on the CDR routeing function specified in 
subclause 5.1.2, then it shall be able to send the different files to different BD systems, i.e. the BD address is part of the 
CDR file routeing filter. 

As a minimum, the following events shall be capable of triggering a file push in the CGF: 

• A (configured number of) new CDR file(s) has become available for transmission; 

• The CDR file / files has / have exceeded a configurable (total) size limit; 

• A configurable, regular time interval has elapsed; 

• The CGF filestore utilization has exceeded a configurable level. 

If the file transfer fails, the CGF should properly reflect this in an error log and generate appropriate alarms. Possible 
measures to handle file transfer failures are discussed in clause 6. 
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Security measures, e.g. the mutual identification / verification of the peer systems, are outside the scope of the present 
document. 

5.4.1.2 Pull mode 

In this transfer mode the BD reads the CDR files that are available in the appropriate CGF directories. The time and/or 
frequency of the file transfer is controlled by the BD. I.e. the BD pulls the files from the CGF. This implies that the 
CGF operates in server mode and the BD in client mode. 

In this mode, the BD may request the files from the CGF at any point in time at the discretion of the BD, i.e. the CGF 
cannot make any assumptions of the time or frequency of the file pull to occur. If the file transfer fails, any further 
action is up to the BD, however, the CGF should properly reflect this in an error log and generate appropriate alarms. 
Possible measures to handle file transfer failures are discussed in clause 6. 

Security measures, e.g. the mutual identification / verification of the peer systems, are outside the scope of the present 
document. 

5.4.2 Use of File Transfer IRP 

File transfer modes and session management using the optional File Transfer IRP are governed by 3GPP TSs 
32.341 [500], 32.342 [501], 32.343 [502] and 32.344 [503]. 



CDR file format specification 



This clause provides detail specifications for the CDR file format. These specifications apply to all domains, 
subsystems and services listed in clause 4. Alternatively, in the CS domain (i.e. for Be), the file transfer mechanism 
specified in 3GPP TS 32.250 [10] may be used. Consequently, for Be it is up to implementation choice to provide either 
the legacy interface, the interface specified in the present document, or both. 

The file format specification in this clause is divided into the following categories: 

• File format conventions; 

• File naming and directory conventions; 

• Detailed file transfer and session management procedures. 

• Error handling 

Only the basic file transfer mechanism is covered in the present document. Refer to 3GPP TSs 32.341 [500], 
32.342 [501], 32.343 [502] and 32.344 [503] for the corresponding details when using the optional File Transfer IRP. 

6.1 File format conventions 

The file format shall apply the following conventions. 

a) The CDR files contain a variable length file header immediately followed by a variable number (zero or more) of 
concatenated CDRs which are structured according to the CDR format specified in the middle tier charging TSs. 

b) The syntax and encoding rules for the CDRs are specified in 3GPP TS 32.298 [51]. 

c) Each CDR is immediately preceded by a fixed length plain text header. 

d) The file header fields and CDR header fields are in Network byte order (Big Endian). 

e) The file header contains fields specified in subclause 6.1.1. 

f) The CDR header contains fields specified in subclause 6.1.2. 

g) File header fields that are not known at the time the file is opened are populated after all the CDRs are included 
and the file is ready to be closed. 
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The CDR file is named based on the naming convention specified in clause 6.2. 



6.1.1 CDR file header format 

The exact format of the CDR file header is given in figure 6. 1. 



Bits 


Octets 


8 1 7 1 6 |5|4|3|2|1 


1..4 


File length 


5..8 


Header length 


9 


High Release Identifier 


High Version Identifier 


10 


Low Release Identifier 


Low Version Identifier 


11. .14 


File opening timestamp 


15.. 18 


Timestamp when last CDR was appended to file 


19..22 


Number of CDRs in file 


23..26 


File sequence number 


27 


File Closure Trigger Reason 


28..47 


IP Address of Node that generated file 


48 


Lost CDR indicator 


49..50 


Length of CDR routeing filter 


51. .xy 


CDR routeing filter 


xy+1..xy+2 


Length of Private Extension 


xy+3..n 


Private Extension 



Figure 6.1 : Format of CDR File Header 

The following subclauses specify the contents and encoding of the CDR file header fields. Unless otherwise specified in 
the subclauses below, all parameters are mandatory and shall always be included in a CDR file header. 



6.1.1.1 



File length 



The 'file length' parameter contains a binary encoded decimal (bed) integer value that identifies the total length of the 
CDR file in octets, including the file header and the total CDR payload length. 

The value with all bits set to '1' is reserved for future extensions (e.g. for CDR files longer than that value) and shall 
therefore not be used. 



6.1.1.2 



Header length 



The 'header length' parameter contains a bed encoded integer value that identifies the total length of the CDR file header 
in octets. 

The value with all bits set to '1' is reserved for future extensions (e.g. for CDR file headers longer than that value) and 
shall therefore not be used. 

6.1 .1 .3 High release / version identifier 

This field is a copy of octet 3 of the CDR header. It is copied from the CDR where the equation: 

Release Identifier * 100 + Version Identifier 

yields the highest result of all CDRs in the file. The representation of Release Identifier and Version Identifier in this 
field is the same as in octet 3 of the CDR header. 

6.1 .1 .4 Low release / version identifier 

This field is a copy of octet 3 of the CDR header. It is copied from the CDR where the equation: 

Release Identifier * 100 + Version Identifier 

yields the lowest result of all CDRs in the file. The representation of Release Identifier and Version Identifier in this 
field is the same as in octet 3 of the CDR header. 
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6.1.1.5 File opening timestamp 

This parameter indicates the time when the file was opened, according to the following format: 

■ The first four bits indicate the month (1 .. 12) in bed representation, according to the CGF"s local time 
zone; 

■ The next five bits contain the date (1 :: 31) in bed representation, according to the CGF"s local time zone; 

■ The next five bits contain the hour (0 .. 23) in bed representation, according to the CGF"s local time zone; 

■ The next six bits contain the minute (0 .. 59) in bed representation, according to the CGF"s local time zone; 

■ The next bit indicates the sign of the local time differential from UTC (bit set to '1' expresses '+' or bit set to 
'0' expresses '-' time deviation), in case the time differential to UTC is then the sign may be arbitrarily set 
to"+"or"-"; 



■ The next five bits contain the hour (0 .. 23) deviation of the local time towards UTC, according to the 
CGF"s local time zone; 

■ The next six bits contain the minute (0 .. 59) deviation of the local time towards UTC, according to the 
CGF"s local time zone; 

Note that the CDR file name contains detailed date and time information related to file closure (cf. clause 6.2) 

6.1.1.6 Last CDR append timestamp 

This parameter indicates the time when the last CDR was appended to the file in UTC format. In case of an empty file 
(i.e. no CDRs included), the value of the parameter corresponds to bed '0'. 

6.1.1.7 Number of CDRs in file 

This parameter contains a bed encoded integer that specifies the total number of CDRs that are included in the file. 

The value with all bits set to '1' is reserved for future extensions (e.g. for CDR files containing more CDRs than 
represented by that value) and shall therefore not be used. 

6.1.1.8 File sequence number 

This parameter is an integer value in bed encoding that contains a running number of the CDR file generated by the 
same CGF. The first file of a CGF is indicated by the value '0'. When the maximum number of file is reached (all bits 
set to '1'), the sequence shall be restarted with '0'. 

6.1 .1 .9 File Closure Trigger Reason 

The file closure reason provides a means to determine the reason that the file was closed by the CGF. It is encoded as a 
single octet as follows. 

Normal closure reasons (Decimal values to 127): 

= Normal closure (Undefined normal closure reason). 

1 = File size limit reached (OA&M configured). 

2 = File open-time limit reached (OA&M configured). 

3 = Maximum number of CDRs in file reached (OA&M configured). 

4 = File closed by manual intervention. 

5 = CDR release, version or encoding change. 

6 to 127 are reserved for future use. 
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Abnormal closure reasons (Decimal values 128 to 255): 

128 = Abnormal file closure (Undefined error closure reason). 

129 = File system error. 

130 = File system storage exhausted. 
131= File integrity error. 

132 to 255 are reserved for future use. 

6.1.1.10 Node IP address 

This parameter indicates the IP address of the CGF that generated the file. For both IPv4 and IPv6 CGF addresses, the 
parameter is encoded in IPv6 representation. 

6.1.1.11 Lost CDR indicator 

This parameter indicates if and how many CDRs were lost during their processing in the CGF (cf. clause 5.1.1). The 
term 'lost' implies that the CDR(s) could not be placed into the destination file due to irrecoverable errors. 

Due to the possibility that the irrecoverable CDR errors may have impacted CDR parameters that are relevant for CDR 
routeing, it is possible that the CGF cannot determine for a particular file whether CDRs have been lost. Appropriate 
indication shall be given according to the following encoding of the 'lost CDR indicator'. 

■ MSB bit '0', all other bits '0': no CDRs have been lost; 

■ MSB bit '0', all other bits set to a value corresponding to decimal 1 to decimal 126: CGF has identified that 
a number of CDRs corresponding to the value of the lower 7 bits were lost, while it is unknown whether 
more CDRs were lost; 

■ MSB bit '0', all other bits set to '1': CGF has identified that 127 or more CDRs were lost, while it is 
unknown whether more CDRs were lost; 

■ MSB bit '1', all other bits '0': CDRs have been lost but CGF cannot determine the number of lost CDRs; 

■ MSB bit '1', all other bits set to a value corresponding to decimal 1 to decimal 126: CGF has calculated the 
number of lost CDRs as indicated in the value of the lower 7 bits; 

■ MSB bit '1', all other bits set to '1': CGF has calculated the number of lost CDRs to be 127 or more. 

6.1 .1 .1 2 Length of CDR routeing filter 

This parameter contains a bed encoded integer value that specifies the length of the subsequent CDR routeing filter in 
octets. The value excludes the two octets of the 'length' parameter itself. 

The value of '65535' (all bits set to '1') is reserved for future extensions (e.g. for CDR routeing filters longer than 65534 
octets) and shall therefore not be used. 

6.1.1.13 CDR routeing filter 

This parameter indicates the filter that determined the routeing of CDRs into this file. Its encoding is vendor specific. 

6.1.1.14 Length of private extension 

This parameter contains a bed encoded integer value that specifies the length of the subsequent 'private extension' field 
in octets. It is present only if a private extension field is included in the CDR file header. Its value excludes the two 
octets of the 'length' parameter itself. 

The value of '65535' (all bits set to '1') is reserved for future extensions (e.g. for private extensions longer than 65534 
octets) and shall therefore not be used. 
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6.1.1.15 Private extension 

This optional field contains a vendor specific private extension to the CDR file header, if any. Its encoding, if present, is 
vendor specific. 

6.1.2 CDR header format 

The exact format of the CDR header is given in figure 6.2 below. 



Bits 


Octets 


8 1 7 1 6 


5 1 4 


1 3 1 2 


1 


1..2 


CDR length 


3 


Release Identifier 


Version Identifier 


4 


Data Record Format 


TS number 



Figure 6.2: Format of CDR Header 

The following subclauses specify the contents and encoding of the CDR header fields. 

6.1.2.1 CDR length 

This field contains a bed encoded integer value that specifies the length of the subsequent CDR, excluding the 4 header 
octets. The value of '65535' (all bits set to '1') is reserved for future extensions (e.g. for CDRs longer than 65534 octets) 
and shall therefore not be used. 

6.1.2.2 Release Identifier 

This field contains a bed encoded integer value that identifies the 3GPP Release of the Technical Specification indicated 
in 'TS number' (see 6.1.2.5 below). Its value is set / used according to the following rules: 

■ If 'TS number' indicates a Rel-99 3GPP TS (TS 32.005 or TS 32.015), then this parameter shall be ignored; 

■ If 'TS number' indicates a Rel-4 3GPP TS (TS 32.205, TS 32.215 or TS 32.235), then this parameter shall be 
set to bed '0', i.e. all bits set to '0'; 

■ If 'TS number' indicates a Rel-5 3GPP TS (TS 32.205, TS 32.215, TS 32.225 or TS 32.235), then this 
parameter shall be set to bed '7', i.e. all bits set to '1'; 

■ Otherwise, i.e. for Rel-6 and following, its value corresponds to the 3GPP Release number - 6 (i.e. '0' for Rel- 
6, and incremented by '1' for each subsequent Release). 

6.1.2.3 Version Identifier 

This field contains a bed encoded integer value that identifies the version of the 3GPP Technical Specification indicated 
in 'TS number' (see 6.1.2.5 below). Its value corresponds to the middle digit of the version number of that TS, as 
indicated on the TS cover sheet. 

6.1 .2.4 Data Record Format 

This field contains a bed encoded integer value that identifies the CDR encoding according to the following table: 

■ '1' signifies the use of Basic Encoding Rules (BER); 

■ '2' signifies the use of unaligned basic Packed Encoding Rules (PER); 

■ '3' signifies the use of aligned basic Packed Encoding Rules (PER); 

■ '4' signifies the use of XML Encoding Rules (XER). 
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6.1.2.5 TS number 

This field contains a bed eneoded integer value that identifies the number of the TS CDR encoding according to the 
following table: 

'0' signifies Rel-99 TS 32.005 

'1' signifies Rel-99 TS 32.015 

'2' signifies Rel-4/5 TS 32.205 

'3' signifies Rel-4/5 TS 32.215 

'4' signifies Rel-5 TS 32.225 

'5' signifies Rel-4/5 TS 32.235 

'6' signifies Rel-6 TS 32.250 

7' signifies Rel-6TS 32.251 

'8' signifies Rel-6 TS 32.252 

'9' signifies Rel-6 TS 32.260 

'10' signifies Rel-6 TS 32.270 

'11' signifies Rel-6 TS 32.271 

'12' signifies Rel-6 TS 32.272 

'13' signifies Rel-6 TS 32.273 



6.2 CDR file naming convention 



The file naming convention ensures that CDR file names are unique among a large number of CGF nodes over an 
extended period of time (at least several months). In order to accomplish this requirement, the file name includes the 
following information: 

<NodeID>_-_<RC>.<date>_-_<time>[.<PI>][.<FE>] 

1) NodelD. This is the name of the CGF that generated the file. When the CGF is integrated in another node (see 
3GPP TS 32.240 [1]), then this parameter contains the NodelD of the node that the CGF is integrated in. 

2) The RC parameter is a running count, starting with the value of "1". Note that the delimiter preceding this field is 
made up of an underscore character (_), followed by a minus character (-), followed by another underscore 
character (-). 

3) The 'date' field indicates the date when the CDR file was closed. It is of the form YYYYMMDD, where: 

YYYY is the year in four-digit notation; 
MM is the month in two digit notation (01 - 12); 
DD is the day in two-digit notation (01 - 31). 
Note that this field is preceded by a point (.) character as delimiter. 

4) The 'time' field indicates the time when the CDR file was closed. It is of the form HHMMshhmm, where: 

HH is the two-digit hour of the day (local time), based on 24-hour clock (00 - 23); 

MM is the two digit minute of the hour (local time); 

s is the sign of the local time differential from UTC (+ or -), in case the time differential to UTC is then the 
sign may be arbitrarily set to "+" or "-"; 
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hh is the two-digit number of hours of the local time differential from UTC (00-23); 

mm is the two digit number of minutes of the local time differential from UTC (00-59). 

Note that the delimiter preceding this field is made up of an underscore character (_), followed by a minus 
character (-), followed by another underscore character (-). 

5) Optional private information. The content of this field is implementation specific. This field, if present, is 
preceded by a point (.) character delimiter. 

6) Optional file extension. The content of this field is implementation specific. This field, if present, is preceded by 
a point (.) character delimiter. 

Some examples describing file-naming convention (note that the quotation marks do not form part of the file name): 

1) file name: 'CGFNodeId_-_1234.20050401_-_2315H-0200', 

meaning: file #1234 produced by CGF <CGFNodeId> on April 1, 2005 at 23: 15 local time, with a time 
differential of H-2 hours against UTC. 

2) file name: 'CGFNodeId_-_44.20051224_-_1700-1130.thankgoditschristmas.abc', 

meaning: file #44 produced by CGF <CGFNodeId> on December 24, 2005 at 17:00 local time, with a time 
differential of -11:30 hours against UTC, private information 'thankgoditschristmas' and extension 'abc'. 

3) file name: 'CGFNodeId_-_44.20051224_-_1700-1130..abc', 

meaning: same file as 2) above but this time without private extension. Note that there are two point characters 
(.) preceding the file extension due to the missing (=empty) private extension. 

There shall be a configurable base directory on the CGF which contains one or more subdirectories that contain all 
CDR files that are ready for transfer to the BD. Further details of the directory structure on the CGF for the storage of 
CDR files are implementation specific. 

6.3 Detailed FTP transfer and session management procedures 

The detailed FTP transfer and session management procedures are out of scope of the current 3GPP release. However 
the following items should be considered in actual implementations. 

• FTP client behaviour; 

• FTP server role; 

• File transfer triggers; 

• Each of the above in relation to push and pull modes. 



6.4 Error handling 



The detailed error handling on the CGF is out of scope of the current 3GPP release. However the following items 
should be considered in actual implementations. 

• Replacement of invalid CDR parameters; 

• Handling of irrecoverable CDRs; 

• System dependent failures (file system full, etc.); 

• File transfer failure in relation to 

■ Pull mode; 

■ Push mode. 
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